멀티 에이전트 역할을 나누는 기준

목차

• #여러 명처럼 보이는 것과 분산 작업은 다르다
• #먼저 단일 에이전트로 충분한지 판단한다
• #좋은 분할은 작업 의존 그래프에서 시작한다
• #역할 이름보다 계약을 먼저 쓴다
• #병렬화할 수 있는 입력을 분리한다
• #쓰기 소유권을 겹치지 않게 한다
• #권한과 신뢰 경계로 역할을 나눈다
• #Orchestrator와 Worker의 책임
• #Reviewer가 독립적이려면 필요한 조건
• #에이전트 간 메시지는 산출물로 제한한다
• #충돌과 의견 차이를 해결하는 방법
• #정적 역할과 동적 역할 생성
• #재구성한 역할 계약 예제
• #비용과 지연을 계산한다
• #멀티 에이전트 실패 패턴
• #평가와 관찰 지표
• #마무리
• #참고 자료
• #관련 노트

여러 명처럼 보이는 것과 분산 작업은 다르다

멀티 에이전트 demo에서는 역할을 다음처럼 만드는 경우가 많다.

agents:
  - product_manager
  - senior_developer
  - security_reviewer
  - final_editor

이름만 보면 전문 조직 같다. 하지만 네 agent가 같은 사용자 요청과 같은 저장소 전체를 읽고, 자유로운 자연어로 의견을 주고받으며, 같은 파일을 수정한다면 역할 분리가 거의 없다.

PM       -> 구현 방법까지 작성
Developer -> 요구사항을 다시 해석
Reviewer  -> 코드를 고치며 새 기능 추가
Editor    -> 앞 단계 결정을 다시 바꿈

역할 설명이 길어질 뿐 실제로는 동일한 모델 호출이 문맥을 반복 소비한다. 책임과 산출물의 경계가 없으므로 오류가 어디서 생겼는지 알기도 어렵다.

멀티 에이전트의 핵심은 모델에게 다른 인격을 부여하는 것이 아니라 다음 중 하나를 얻는 데 있다.

• 서로 독립적인 탐색을 병렬로 수행한다.
• 각 작업에 필요한 문맥만 제공해 context를 줄인다.
• 도구와 데이터 권한을 역할별로 제한한다.
• 생성과 검증을 독립된 경로로 분리한다.
• 장시간 작업을 작은 durable unit으로 관리한다.

먼저 단일 에이전트로 충분한지 판단한다

멀티 에이전트는 조정 비용이 있다. 작은 작업은 하나의 agent와 명시적인 단계만으로 더 안정적일 수 있다.

flowchart TD
    A[작업 요청] --> B{독립 탐색 축이 여러 개인가?}
    B -- 아니오 --> S[단일 에이전트]
    B -- 예 --> C{결과를 별도 계약으로 합칠 수 있는가?}
    C -- 아니오 --> S
    C -- 예 --> D{병렬화 이익이 조정 비용보다 큰가?}
    D -- 아니오 --> S
    D -- 예 --> E{권한 또는 독립 검증 경계가 필요한가?}
    E -- 예 --> M[멀티 에이전트]
    E -- 아니오 --> P[소규모 병렬 Worker 검토]

단일 agent가 적합한 경우는 다음과 같다.

• 다음 단계가 이전 단계의 세부 결과에 강하게 의존한다.
• 작은 파일 하나를 수정하고 test하는 작업이다.
• 공유 문맥이 크고 역할별로 자르기 어렵다.
• 최종 결과를 합치는 비용이 작업 자체보다 크다.
• 별도 agent를 평가할 test나 schema가 없다.

여러 agent가 유리할 가능성이 높은 경우도 있다.

• 서로 다른 자료원을 넓게 탐색해야 한다.
• frontend, backend, infrastructure처럼 소유 파일이 분리된다.
• 독립적인 보안·성능·정확성 검토가 필요하다.
• 여러 가설을 동시에 실험하고 결과를 비교한다.
• tool 권한을 최소 범위로 나눠야 한다.

Anthropic의 multi-agent research system도 lead agent가 서로 다른 연구 방향을 병렬 subagent에게 맡기는 orchestrator-worker 구조를 설명한다. 중요한 것은 agent가 많다는 사실보다 탐색 방향이 독립적이라는 점이다.

좋은 분할은 작업 의존 그래프에서 시작한다

역할 목록부터 만들지 말고 완료해야 할 산출물과 의존 관계를 그린다.

flowchart LR
    R[요구사항 계약] --> A[API 영향 분석]
    R --> B[DB 변경 분석]
    R --> C[보안 위협 분석]
    A --> I[구현 Patch]
    B --> I
    C --> I
    I --> T[테스트 결과]
    I --> S[보안 검토]
    T --> G[통합 판단]
    S --> G

이 그래프에서 A, B, C는 같은 요구사항을 입력으로 받고 서로의 결과 없이 시작할 수 있으므로 병렬화 후보다. 구현 I는 세 결과에 의존한다. 테스트 T와 보안 검토 S는 구현 patch를 공통 입력으로 받지만 서로 독립적으로 진행할 수 있다.

다음 질문으로 node를 agent role로 승격할지 판단한다.

1. 입력을 고정된 snapshot이나 schema로 전달할 수 있는가?
2. 다른 node와 동시에 실행해도 되는가?
3. 산출물을 자동 또는 독립적으로 검증할 수 있는가?
4. 필요한 도구와 권한이 다른가?
5. 실패해도 다른 node의 상태를 훼손하지 않는가?
6. 재시도할 때 전체 workflow가 아니라 이 node만 반복할 수 있는가?

답이 대부분 아니라면 별도 agent보다 같은 agent 내부의 순차 단계가 낫다.

역할 이름보다 계약을 먼저 쓴다

security expert라는 이름은 무엇을 검사하고 무엇을 반환하는지 말하지 않는다. 다음처럼 계약으로 정의한다.

role: security_review
input:
  base_revision: immutable git commit
  patch: unified diff
  threat_model: threat-model-v3
allowed_tools:
  - repository.read
  - static_analysis.run
output:
  schema: security-findings-v2
  required_fields:
    - severity
    - file
    - line
    - evidence
    - remediation
write_scope: none
completion:
  - every changed entry point reviewed
  - unresolved findings listed explicitly

좋은 역할 계약은 경계를 선명하게 한다.

자연어 보고서가 필요하더라도 machine-readable summary를 함께 반환하면 orchestration이 안정적이다.

{
  "role": "security_review",
  "decision": "CHANGES_REQUIRED",
  "reviewedRevision": "abc123",
  "patchHash": "sha256:example",
  "findings": [
    {
      "severity": "HIGH",
      "file": "src/example.ts",
      "line": 42,
      "evidence": "untrusted redirect target is fetched",
      "remediation": "validate the resolved address before each request"
    }
  ]
}

병렬화할 수 있는 입력을 분리한다

두 agent가 같은 mutable workspace를 보며 동시에 작업하면 시작 시점과 종료 시점의 세계가 달라진다. 입력을 immutable snapshot으로 고정한다.

role input
  repositoryRevision = abc123
  requirementVersion = req-7
  upstreamArtifactHash = sha256:9f...

연구 작업이라면 탐색 범위를 겹치지 않게 나눈다.

research_tracks:
  - id: database
    question: "transaction과 lock 관점의 실패 조건"
    allowed_sources: [official_database_docs]
  - id: security
    question: "권한과 데이터 유출 위협"
    allowed_sources: [standards, official_security_guides]
  - id: operations
    question: "관찰 지표와 복구 절차"
    allowed_sources: [official_platform_docs]

“각자 이 주제를 조사해 와”라고 하면 같은 상위 검색 결과를 반복할 가능성이 높다. 질문, source constraint와 제외 범위를 달리해야 병렬 탐색의 recall이 늘어난다.

완전히 독립적이지 않은 작업을 억지로 병렬화하면 후속 agent가 낡은 가정으로 작업한다. Dependency graph에서 선행 artifact가 확정된 뒤 다음 node를 시작한다.

쓰기 소유권을 겹치지 않게 한다

코딩 작업에서 가장 흔한 충돌은 여러 agent가 같은 파일을 동시에 수정하는 것이다.

Agent A: API handler와 DTO 수정
Agent B: 같은 DTO를 DB 요구에 맞게 수정
Agent C: formatter 실행으로 저장소 전체 변경

Git merge가 성공해도 의미 충돌은 남을 수 있다. 대응 방식은 세 가지다.

경로로 나눈다

ownership:
  frontend_agent:
    write: ["apps/web/"]
  api_agent:
    write: ["services/api/"]
  infra_agent:
    write: ["deploy/"]

경로가 명확히 분리된 monorepo 작업에 적합하다. 공용 type이나 schema는 별도 integration role만 수정하게 한다.

Patch 제안만 받는다

각 agent가 workspace를 직접 수정하지 않고 diff를 제출하고 orchestrator가 순서대로 적용한다.

Worker A -> patch A + base hash
Worker B -> patch B + base hash
Integrator -> A 적용 -> test -> B rebase -> test

충돌 비용은 integrator에 모이지만 원본 상태가 예측 가능하다.

한 명만 쓰고 나머지는 읽는다

Implementer만 write 권한을 갖고 reviewer와 tester는 snapshot을 읽어 finding을 반환한다. 작은 팀에서는 이 방식이 가장 단순하다.

권한과 신뢰 경계로 역할을 나눈다

작업 종류가 같아도 필요한 권한이 다르면 역할을 분리할 가치가 있다.

Researcher   read web, write evidence artifact
Implementer  read repository, write isolated workspace
Reviewer     read patch and tests, no write
Deployer     read approved artifact, deploy only

모든 agent에 모든 tool을 주면 하나가 prompt injection에 노출됐을 때 전체 시스템이 영향을 받는다. AI 에이전트 권한을 최소화하는 방법의 원칙에 따라 task와 role의 교집합으로 capability를 만든다.

type RoleCapability = {
  role: "RESEARCHER" | "IMPLEMENTER" | "REVIEWER" | "DEPLOYER";
  actions: string[];
  resources: string[];
  expiresAt: string;
};

function intersectCapabilities(
  taskAllowed: Set<string>,
  roleAllowed: Set<string>,
): Set<string> {
  return new Set([...roleAllowed].filter((action) => taskAllowed.has(action)));
}

Deployer에게 source 수정 권한이 필요하지 않고, implementer에게 production credential이 필요하지 않다. 최종 승인과 실행은 사람의 승인을 영속 상태로 저장해야 하는 이유처럼 구체적 artifact hash에 묶는다.

Orchestrator와 Worker의 책임

Orchestrator-worker 구조에서는 중앙 조정자가 목표를 작업으로 나누고 worker의 결과를 합친다. 조정자가 모든 세부 작업까지 다시 수행하면 병목과 single context overload가 생긴다.

sequenceDiagram
    participant O as Orchestrator
    participant R as Research Worker
    participant I as Implementation Worker
    participant V as Review Worker
    O->>R: research contract + budget
    R-->>O: evidence artifact
    O->>I: requirement + evidence hash
    I-->>O: patch + test manifest
    O->>V: patch snapshot + review contract
    V-->>O: findings
    O->>O: completion criteria 평가

Orchestrator가 worker의 자연어를 무조건 신뢰하지 않고 artifact schema, hash와 자동 test를 검증해야 한다. Worker가 “테스트 통과”라고 말하는 것과 실제 exit code·log checksum을 반환하는 것은 다르다.

Reviewer가 독립적이려면 필요한 조건

같은 agent가 코드를 만든 직후 “내 코드의 문제를 찾아라”는 prompt를 받으면 이전 추론에 anchoring될 수 있다. 별도 reviewer가 유용하려면 독립성을 실제로 만들어야 한다.

Reviewer에게 제공
  - 요구사항과 invariant
  - base revision과 patch
  - test evidence
  - review checklist

Reviewer에게 숨기거나 제한
  - implementer의 자기 변호식 reasoning
  - 불필요한 전체 대화
  - write와 merge 권한

Reviewer output은 호불호가 아니라 검증 가능한 finding이어야 한다.

type ReviewFinding = {
  id: string;
  category: "CORRECTNESS" | "SECURITY" | "PERFORMANCE" | "MAINTAINABILITY";
  severity: "LOW" | "MEDIUM" | "HIGH";
  location?: { file: string; line: number };
  invariantViolated: string;
  evidence: string;
  suggestedCheck: string;
};

Reviewer가 직접 고치기 시작하면 finding과 수정 책임이 섞인다. 먼저 finding을 고정하고 implementer가 대응 patch를 만들며, reviewer는 새 patch에서 해결 여부만 판단하게 할 수 있다.

에이전트 간 메시지는 산출물로 제한한다

Agent들이 자유 대화를 오래 이어가면 정보가 반복 압축되고 출처가 사라진다.

Agent A: 아마 공식 문서가 이렇게 말한 것 같다.
Agent B: A의 요약을 보면 확실한 것 같다.
Agent C: 두 agent가 동의했으니 채택한다.

합의 수가 증거의 품질을 높이지 않는다. 메시지에 claim, evidence와 uncertainty를 분리한다.

{
  "claim": "조건부 update는 revision이 일치할 때만 재시도할 수 있다",
  "evidence": [
    {
      "source": "official-doc-url",
      "retrievedAt": "2026-05-12T00:00:00Z",
      "supports": "precondition behavior"
    }
  ],
  "confidence": "HIGH",
  "openQuestions": ["보존 기간이 workflow deadline보다 긴가"]
}

큰 원문 전체를 다음 agent에게 넘기기보다 content-addressed artifact store에 저장하고 필요한 section과 hash를 전달한다. 다만 요약 agent가 중요한 예외를 버릴 수 있으므로 최종 결정자는 근거 원문에 접근할 수 있어야 한다.

충돌과 의견 차이를 해결하는 방법

두 reviewer가 다른 결론을 내렸을 때 단순 다수결은 위험하다. 같은 model과 prompt 계열이면 오류가 상관되어 있기 때문이다.

Security reviewer: redirect 허용은 SSRF 위험
Product reviewer: 고객 URL preview에 필요

이 문제는 누가 더 자신 있게 말하는지가 아니라 invariant와 trade-off를 상위 결정으로 올려야 한다.

conflict:
  subject: external_redirect
  option_a:
    decision: deny
    protected_invariant: no_private_network_access
  option_b:
    decision: allow_via_proxy
    required_controls:
      - resolve_and_validate_each_hop
      - egress_proxy
      - response_size_limit
  unresolved_by: security_and_product_workers
  owner: orchestrator_or_human

충돌 해결 우선순위를 정해 둘 수 있다.

1. 자동 test와 schema 같은 결정적 증거
2. 명시된 security·business invariant
3. authoritative source와 재현 가능한 실험
4. role owner의 판단
5. 영향이 큰 비가역 결정은 사람의 승인

“토론을 더 시킨다”는 종료 조건이 없으면 token만 늘어난다. 최대 round와 escalation 조건을 둔다.

정적 역할과 동적 역할 생성

반복 workflow는 미리 정의한 정적 role이 안정적이다.

workflow: repository_change
roles:
  - impact_analyzer
  - implementer
  - test_runner
  - security_reviewer
  - integrator

연구처럼 질문마다 탐색 축이 달라지면 orchestrator가 동적으로 subtask를 만들 수 있다. 그래도 무제한 생성은 막아야 한다.

type DelegationBudget = {
  maxWorkers: number;
  maxDepth: number;
  maxTotalTokens: number;
  deadlineAt: string;
};

function canDelegate(state: WorkflowState): boolean {
  return (
    state.activeWorkers < state.budget.maxWorkers &&
    state.depth < state.budget.maxDepth &&
    state.tokensUsed < state.budget.maxTotalTokens &&
    Date.now() < Date.parse(state.budget.deadlineAt)
  );
}

동적 role도 최소 계약을 가져야 한다. question, inputArtifacts, allowedTools, outputSchema, budget, stopCondition이 없으면 생성하지 않는다.

재구성한 역할 계약 예제

다음은 코드 변경 workflow를 위한 가상의 TypeScript 모델이다.

type ArtifactRef = {
  id: string;
  kind: "REQUIREMENT" | "EVIDENCE" | "PATCH" | "TEST_RESULT" | "FINDINGS";
  sha256: string;
  schemaVersion: string;
};

type RoleContract = {
  roleId: string;
  objective: string;
  inputs: ArtifactRef[];
  allowedTools: string[];
  writeScopes: string[];
  outputKind: ArtifactRef["kind"];
  completionChecks: string[];
  maxToolCalls: number;
  deadlineAt: string;
};

const securityReview: RoleContract = {
  roleId: "security-review",
  objective: "변경된 entry point가 정의된 보안 invariant를 위반하는지 찾는다",
  inputs: [requirementArtifact, patchArtifact, testArtifact],
  allowedTools: ["repository.read", "static-analysis.run"],
  writeScopes: [],
  outputKind: "FINDINGS",
  completionChecks: [
    "patch hash가 입력과 일치함",
    "모든 변경 entry point가 검토됨",
    "finding마다 evidence 또는 재현 절차가 있음",
  ],
  maxToolCalls: 20,
  deadlineAt: "2026-05-12T01:00:00Z",
};

Orchestrator는 worker의 결과를 저장하기 전에 계약을 검사한다.

async function acceptResult(
  contract: RoleContract,
  result: WorkerResult,
): Promise<ArtifactRef> {
  if (result.roleId !== contract.roleId) throw new Error("role mismatch");
  if (result.outputKind !== contract.outputKind) throw new Error("output mismatch");
  if (!result.inputHashes.every((hash) =>
    contract.inputs.some((input) => input.sha256 === hash),
  )) {
    throw new Error("result was produced from unexpected input");
  }

  await schemas.validate(result.outputKind, result.payload);
  await policy.assertNoWriteOutsideScope(result.audit, contract.writeScopes);
  return artifacts.storeImmutable(result);
}

이렇게 하면 결과가 어느 입력 version에서 만들어졌는지 추적하고, 입력이 바뀌면 stale artifact를 무효화할 수 있다.

비용과 지연을 계산한다

병렬화는 wall-clock time을 줄일 수 있지만 총 token과 tool 비용은 늘어난다.

단일 agent 비용
  = 공통 문맥 1회 + 작업 단계별 증분

N개 worker 비용
  = 공통 문맥 N회 + 각 탐색 + orchestrator 통합 + agent 간 전달

멀티 에이전트가 유리하려면 대략 다음 조건을 만족해야 한다.

병렬화로 줄어드는 지연 + 탐색 품질 이익 + 권한 분리 이익
  > 중복 context + orchestration + 통합 + 실패 복구 비용

모든 요청을 multi-agent로 보내지 말고 complexity classifier나 명시적 threshold로 route한다. 작은 질문은 단일 agent, 넓은 연구나 여러 독립 artifact가 필요한 작업은 여러 worker로 보낸다.

멀티 에이전트 실패 패턴

역할만 다르고 입력과 도구가 같다

결과가 중복되고 오류도 상관된다. 탐색 질문, source와 tool을 실제로 분리한다.

모두가 coordinator다

각 agent가 다시 일을 나누기만 하고 산출물을 만들지 않는다. delegation depth와 leaf worker의 output 계약을 둔다.

모두가 같은 파일을 수정한다

merge conflict와 의미 충돌이 쌓인다. single writer, path ownership 또는 patch-only 방식을 사용한다.

Reviewer가 구현자의 결론을 그대로 받는다

독립 검토가 아니라 요약 확인이 된다. requirement, patch와 test evidence를 중심으로 새로운 context를 제공한다.

Agent가 다른 Agent의 말을 신뢰된 명령으로 실행한다

한 agent가 오염되면 prompt injection이 연쇄 전파된다. Agent message를 untrusted data로 취급하고 schema와 policy gateway를 거친다.

종료 조건이 없다

서로 검토와 반론을 반복한다. 최대 round, budget, confidence가 아니라 검증 가능한 completion criterion을 둔다.

최종 책임자가 없다

결과가 충돌할 때 아무도 결정하지 않는다. Orchestrator나 human owner가 trade-off와 비가역 작업을 최종 결정한다.

평가와 관찰 지표

개별 응답 점수만으로는 역할 분리가 효과적인지 알기 어렵다. single-agent baseline과 workflow 전체를 비교한다.

Trace에는 task, role run과 artifact ID를 연결한다.

{
  "event": "agent.role.completed",
  "taskId": "task-42",
  "roleRunId": "role-run-81",
  "roleId": "security-review",
  "inputArtifactHashes": ["sha256:patch", "sha256:tests"],
  "outputArtifactHash": "sha256:findings",
  "toolCalls": 8,
  "tokensUsed": 12400,
  "elapsedMs": 48120,
  "contractVersion": "security-review-v2"
}

평가 dataset에는 단일 agent로 충분한 작은 작업과 multi-agent가 유리한 넓은 작업을 모두 넣는다. 그래야 복잡한 구조가 모든 요청에 과도하게 적용되는 것을 발견할 수 있다.

마무리

멀티 에이전트 설계는 사람 조직도를 prompt에 옮기는 일이 아니다. 작업의 의존 관계를 분석하고 독립적으로 실행·검증·재시도할 수 있는 단위에 계산과 권한을 배치하는 일이다.

역할은 이름이 아니라 입력, 결정, 도구, 쓰기 소유권, 산출물과 종료 조건으로 정의한다.

실무에서는 다음 기준을 사용할 수 있다.

1. 먼저 단일 agent와 명시적인 workflow 단계로 충분한지 확인한다.
2. 목표를 artifact dependency graph로 나눈다.
3. 서로의 중간 결과 없이 시작 가능한 node만 병렬화한다.
4. Role마다 immutable input과 structured output 계약을 둔다.
5. 같은 파일과 resource의 write owner를 하나로 제한한다.
6. Role과 task 권한의 교집합만 capability로 제공한다.
7. Orchestrator는 상태·budget·의존성과 최종 통합을 담당한다.
8. Worker는 좁은 subtask와 검증 가능한 artifact에 집중한다.
9. Reviewer에게 구현자의 불필요한 reasoning 대신 요구사항과 patch를 제공한다.
10. Agent 간 메시지를 untrusted artifact로 검사한다.
11. 충돌은 다수결보다 invariant와 재현 가능한 증거로 해결한다.
12. Delegation depth, worker 수, token과 시간 budget을 제한한다.
13. Single-agent baseline과 비용·지연·품질을 비교한다.
14. 최종 의사 결정자와 사람에게 escalation할 조건을 정한다.

여러 agent의 장점은 서로 말을 많이 하는 데 있지 않다. 각자 다른 좁은 문제를 책임지고, 결과가 명확한 계약을 통해 합쳐질 때 비로소 병렬성과 전문화가 실제 가치가 된다.

참고 자료

• Anthropic Engineering - How we built our multi-agent research system
• Anthropic Engineering - Building effective agents
• AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation
• Microsoft AutoGen - Multi-agent Conversation Framework

관련 노트

• 분산 추적에서 Trace ID와 Span ID 역할
• LLM 도구 호출에서 제안과 실행 분리하기
• AI 에이전트 권한을 최소화하는 방법
• 에이전트 작업을 샌드박스에서 실행하기
• 사람의 승인을 영속 상태로 저장해야 하는 이유
• 에이전트 재시도와 멱등성
• 에이전트 워크플로우를 상태 머신으로 표현하기